Examining Log4j Vulnerabilities in Connected Cars and Charging Stations

Evidence of attacks using the Log4j vulnerability was also shown in a test that triggered a bug on a Tesla car. For this case, the source does not provide much information on where it was actually executed. Nevertheless, this means that the exploitation of the vulnerability could still have an impact on the user’s privacy and the general security of the car because a back-end compromise could allow attackers to push actions to the car and serve malicious firmware over-the-air (FOTA) updates.

Digital keys vulnerable to Log4Shell?

Smartphones can now replace key fobs as so-called “digital keys” that can control some parts of cars. The applications that allow this could also be vulnerable to the Log4j vulnerability. The Frida script log4JFrida can be used to test this assumption, allowing one to change several characteristics of a car to trigger the vulnerability.

Beyond the three devices or properties in modern cars discussed in this article, there are still many more to test and monitor for Log4j vulnerabilities. Among them are servers’ responses to tests and plenty of other vectors that could allow attackers to use the access afforded by applications to send commands that can unlock a car, control the heating, and perform other functions that can be abused by malicious actors.

Up to now, organizations and security experts are still grappling with the full extent of the Log4j vulnerabilities. It is likely that more reports looking into the effects of these vulnerabilities in specific services, devices, or applications will be released in the coming weeks. On the other hand, cybercriminals are also making the most of this time to catch potential victims, including those who are still exposed via unpatched Log4j vulnerabilities, off guard.

The main fix for the vulnerabilities is to update Log4j to version 2.17.0. This version removes the message lookup feature, which provides a way to add values to Log4j’s configuration, entirely. However, in most cases, such as RISE-V2G, using an up-to-date version of Log4j could break applications.

Another option is to enable “formatMsgNoLookups=true” when configuring Log4j or invoking this flag when running Log4j as described in LunaSec’s mitigation guide:

java -Dlog4j2.formatMsgNoLookups=true …

It is also possible to disable logs altogether if they are not needed. RISE-V2G, for example, has an option to do this in its configuration files by disabling EXI and XML display:

# XML representation of messages
#——————————-
#
# Possible values:
# – true
# – false
# If this value is set to ‘true’, the EXICodec will print each message’s XML representation (for debugging purposes)
# If no correct value is provided here, ‘false’ will be chosen
exi.messages.showxml = false
 
# Hexadecimal and Base64 representation of messages
#————————————————–
#
# Possible values:
# – true
# – false
# If this value is set to ‘true’, the EXICodec will print each message’s hexadecimal and Base64 representation (for debugging purposes)
# If no correct value is provided here, ‘false’ will be chosen
exi.messages.showhex = false

We have put up a support page that includes a list of our products that can help with detection and prevention, along with information pertaining to our own products’ being vulnerable or not.

We have also created an assessment tool  for identifying server applications and endpoints that might be affected by the Log4j vulnerabilities. The tool also provides a detailed view of the attack surface and the next steps for mitigating risks.